home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_300 / 331_01 / read.me < prev    next >
Text File  |  1990-06-13  |  25KB  |  439 lines
  1. .ce
  2.                              The SE Editor
  3.  
  4. .fi
  5. .rm 76
  6.  
  7. This file announces the release of yet another of the derivatives of the 'e'
  8. editor.  The highlights of this version are:
  9.  
  10. 1) Utilizes up to 500 kb of RAM for text storage, while functioning with as
  11. little a 6kb of allocatable memory. 2) The efficiency of the virtual disc
  12. system has been doubled by adding a stale page directory.  The speed of disc
  13. reads has been improved. 3) An embedded runoff function will reformat
  14. internal text per dot commands. 4) A text push stack has been added for
  15. pushing and popping lines. 5) The undo capability has been extended to
  16. include redo. 6) The program supports free cursor movement. 7) Numerous
  17. enhancements to the command and display structure have been made, while
  18. retaining Wordstar [1] compatibility where feasible and reasonable.  Many of
  19. the enhancements are cosmetic, not affecting the command structure, but
  20. improving the visibility or convenience of use.
  21.  
  22. The starting point for this system was the GED version, CUG 199.  The
  23. contributors to that version were G.  Nigel Gilbert, James W.  Haefner, and
  24. Mel Tearle.  Several small errors have been corrected.  The new version
  25. compiles under Microsoft 4.00.  This compiler allows selective use of far
  26. pointers, opening up the possibilities of the large memory model without its
  27. usual inefficiency.  Some effort has been made to otherwise maintain
  28. compatibility with the DeSmet starting point, but the thoroughness of the
  29. compatibility has not been tested.
  30.  
  31. The architecture remains that of the earlier versions.  It is a good
  32. architecture, providing a solid foundation for further enhancements and
  33. additions.  Due to the ancestry of the program, the architecture is oriented
  34. to the needs of a slow remote terminal.  In the interest of portability,
  35. that design philosophy has been retained, even though some shortcuts could
  36. have been taken with the direct access to the video RAM in the PC's.  The
  37. shortcuts would compromise the portability of the program.
  38.  
  39. There are preprocessor directives in the header file which can be changed to
  40. remove all occurrences of the near and far keywords, making the code
  41. compatible with compilers which do not support mixed memory models.  Most
  42. users will not find the capabilities of the program running under the small
  43. memory model overly restrictive.  The virtual memory system is effective in
  44. masking the shortcomings of a small RAM.
  45.  
  46. A tidying up operation has been performed, including the addition of many
  47. comments.  The new code, now in its third compiler port, should be mostly
  48. vanilla.  An attempt has been made to further segregate those functions
  49. which are system dependent (IBM PC, MSDOS) to simplify rework for a port to
  50. a different system.  The strategy in porting the system to an entirely
  51. different environment is to replace the system interface routines
  52. altogether.
  53.  
  54. The program is configured for editing a 2.4 megabyte english dictionary
  55. consisting of 10000 lines of 253 characters each.  The maximum file size
  56. will be less for 80-character lines.  The maximum number of lines in a file
  57. is 16383.
  58.  
  59. The line limit may be less for small memory systems, but remains adequate
  60. for most work in any plausible system. 1000 line files can be edited with
  61. only 8 kb of allocatable RAM.  A line pointer array is kept in RAM, so all
  62. line jumps are instantaneous if the text is in RAM, or just the disc access
  63. time (without searching) if all the document won't fit in RAM.  The virtual
  64. memory system keeps the most recently used pages in RAM, as they are the
  65. most likely to be used or viewed again.  Global string searches have little
  66. effect on the established page priorities.  They normally search all pages
  67. and are given special consideration so that they do not upset the virtual
  68. memory priorities established by earlier editing and display functions.
  69.  
  70. Earlier versions unconditionally wrote a page back to disc if the RAM slot
  71. was needed for another use.  This version does not do a disc write if the
  72. virtual memory page is unchanged since being rolled in from disc.  In a
  73. further refinement, the line pointer array and text pages are allocated
  74. beginning from opposite ends of memory, so that they do not collide until
  75. RAM is exhausted.  Collision was immediate in the earlier versions,
  76. resulting in unnecessary disc thrashing during the initial read.  If enough
  77. RAM is available the new version will not create a temporary disc file at
  78. all.
  79.  
  80. Tree directories are supported.  An error in earlier versions which made
  81. filespecs of the form ..\filespec unusable has been corrected.  The
  82. temporary disc file normally goes in the default directory of the default
  83. drive.  The -D invocation option can be used to place the temporary file on
  84. any drive.  In browsing through the files on floppy discs from a hard disc
  85. system, nothing is written to the floppy disc unless directed there from the
  86. keyboard.  Archived files can be studied with little risk of accidental
  87. modification.
  88.  
  89. The program updates the screen before the data base, making it seem faster
  90. than it is in some cases.  In the case of line deletions or insertions, all
  91. the line pointer array beyond the modified point is moved.  The processing
  92. delay is seen if a second key is entered during the move.  The delay becomes
  93. noticeable and objectionable at about 5000 lines on a 5 MHz PC.  The delay
  94. is not objectionable (and rarely seen) with 16000 line documents on an 80286
  95. or faster system.
  96.  
  97. On a 5 MHz PC the primary file is read at the rate of 5200 characters per
  98. second from fixed disc; at 3000 characters per second from floppies.  The
  99. string search operation proceeds at 30,000 characters per second if the
  100. material is in RAM.  The search rate exceeds 200,000 characters per second
  101. on more recent systems.
  102.  
  103. Learning to use any word processor effectively represents a significant
  104. investment in time.  For that reason I have tried to adopt or retain the
  105. Wordstar keyboard layout for the frequent and habitual keystrokes.  But in
  106. the more complex and less frequent functions, and when there is is ample
  107. visual prompting or feedback, significant deviations have been made.
  108.  
  109. Some editing programs trap the cursor within the portion of the screen
  110. containing text for reasons which are surely without merit.  The package has
  111. been modified to allow free cursor movement.  The horizontal domain of the
  112. cursor lies between columns 1 and 255.  The ^D, right arrow, and ^] (end of
  113. line) cursor positioning commands will move the cursor past the right end of
  114. the line.  Doing so creates temporary spaces at the end of the line, but
  115. they are removed before the line is stored.  Editing is performed as though
  116. each line had spaces all the way to the right.  Free cursor movement is a
  117. great convenience in editing C code because the cursor will stay at a fixed
  118. indentation level when moved vertically.
  119.  
  120. The -S option restores the earlier mode.  In this mode the cursor is trapped
  121. within those regions already containing text (or trailing spaces).  In this
  122. mode it is unnecessary to strip trailing blanks before lines are stored, and
  123. they are not.  That is what the mode used for.  But otherwise, the first
  124. time a file passes through SE without the -S option it may shrink in size
  125. without any editing activity.  The thing lost is trailing whitespace.
  126.  
  127. The GED version had a full undo capability, but I quickly discovered that
  128. after undoing more than two lines I had always forgotten what I had changed
  129. and why.  The changes I saw occurring on the screen in time reversal didn't
  130. make any sense.  To overcome that problem I modified the undo algorithm to
  131. be reversible and with that there is redo.  The same algorithm and the same
  132. code is used for both.  The complete algorithm is surprisingly compact.  By
  133. moving back and forth along the edit trail it is usually possible to
  134. recognize the correct restoration point many lines back.  Undo is nice, but
  135. it is redo that makes it work.
  136.  
  137. As each line is undone or redone it appears in reverse field on the screen.
  138. The cursor follows the undone and redone lines about th